Skip to main content

Grupo 7 - MapYourWorld

En esta página se encuentra el feedback recogido por el equipo del grupo 7 durante las sesiones de clase. Con secciones para cada semana, se detallan los comentarios y sugerencias del profesor y los compañeros, así como las tareas a realizar para la siguiente semana. Además, se incluye una sección para cada grupo con el feedback proporcionado por el grupo 7.

Semana 1​

Feedback relacionado con la presentación​

  • La presentación debe transmitir identidad corporativa, definir un manual de identidad visual (logo, colores, tipografías, tamaños) para mantener coherencia.
  • Ajustar el DAFO para que sea más legible y acorde al diseño general.
  • Evitar transparencias sobrecargadas y aprovechar mejor los espacios en blanco.
  • Mensajes claros y compactos, sin textos largos que descoordinen la atención.
  • Evitar presentaciones "subtituladas", la pantalla debe ser soporte, no protagonista.
  • Evitar "presentaciones polvorones", es decir, eliminar elementos innecesarios que distraigan.
  • El elevator pitch debe ser comprensible y con un ritmo más pausado para facilitar la comprensión.
  • Las tablas comparativas mencionadas sobre competidores deben estar incluidas en la presentación.
  • Definir claramente el público objetivo y representarlo con un gráfico claro.

Feedback relacionado con el desarrollo del proyecto​

  • Diferenciar correctamente entre cliente y usuario en el modelo freemium.
  • MVP mal definido, debe representar el mínimo viable para salir al mercado.
  • Relacionar casos de uso core con cada arquetipo de usuario.
  • Mayor rigor en el análisis de competidores, definir criterios de búsqueda y usar tabla comparativa.
  • Diferenciar entre equipos (habilidades) y squads (proyectos concretos).
  • Integrar la IA de manera transversal, no como una característica explícita.
  • Aclarar fases de análisis y diseño.
  • Presentar estructura organizacional clara con roles y habilidades de cada miembro.
  • Para entregas, todo debe ser impreso y organizado en el repositorio común.

Tareas a realizar para la siguiente semana​

  • Refinar la presentación, asegurando identidad visual homogénea.
  • Diseñar mockups que ilustren las funcionalidades clave.
  • Definir con precisión el MVP y sus funcionalidades esenciales.
  • Definir estructura organizativa del equipo con roles y habilidades.
  • Elaborar un análisis riguroso de competidores con criterios bien definidos.
  • Incluir análisis de riesgos según PMBOK.

Semana 2​

Feedback relacionado con la presentación​

  • La presentación debe ser autocontenida, sin referencias a clases anteriores.
  • No incluir información ilegible en diapositivas.
  • Organizar mejor la presentación para mejorar la comprensión visual.
  • Evitar mensajes negativos y estructurar la información de manera clara y directa.
  • Justificar decisiones tomadas con datos concretos.
  • Explicar bien las referencias a gráficos y elementos visuales.
  • Incluir barra de progreso en la presentación.
  • Iniciar la presentación con un mensaje efectivo en los primeros 10 segundos.
  • Usar leyendas claras en los elementos visuales para mejorar su comprensión.

Feedback relacionado con el desarrollo del proyecto​

  • Asegurar que los mockups sean claros, funcionales y cuenten una historia.
  • Definir mejor los competidores, justificando su selección y ordenándolos de manera digerible.
  • Explicar en detalle qué hace cada competidor y su relación con el proyecto.
  • Análisis preliminar de costes debe ser detallado, incluyendo costes de personal y herramientas.
  • Explicar bien la privacidad de datos y su gestión.
  • Definir con claridad qué características se monetizan y quién paga por ellas.
  • Asegurar que la gestión de riesgos esté alineada con debilidades identificadas en DAFO.
  • Commitment Agreement debe estar actualizado y ser detallado con penalizaciones claras

Tareas a realizar para la siguiente semana​

  • Revisar y mejorar la estructura de la presentación, asegurando que sea clara y autocontenida.
  • Refinar el análisis de competidores y justificar su selección.
  • Justificar con datos todas las decisiones de costes y estrategias.
  • Desarrollar mockups funcionales que cuenten una historia clara.
  • Explicar bien la estrategia de monetización y qué características generan ingresos.
  • Incluir gestión de riesgos alineada con DAFO y definir planes de contingencia.
  • Actualizar y especificar el Commitment Agreement.
  • Presentar de manera visual el stack tecnológico del equipo y justificar las elecciones.
  • Definir estructura de roles basada en habilidades y mantenerla estable dentro del sprint.
  • Asegurar que la documentación incluya un plan detallado de los próximos sprints.
  • Implementar herramientas obligatorias como GitHub Actions y GitHub Projects.
  • Desarrollar una landing page clara para explicar la idea principal del proyecto.

Semana 3​

Feedback relacionado con la presentación​

  • Presentación un poco desordenada.
  • El Commitment Agreement está ubicado en medio, lo que afecta la coherencia.
  • Evitar hablar sobre un índice en la presentación.

Feedback relacionado con el desarrollo del proyecto​

  • Cuidado con los costes, no sacar cifras del aire.
  • Investigar las mejores opciones, especialmente en publicidad.
  • Asegurar que todos los lanzamientos sean accesibles.
  • Se puede centralizar en un mismo deployment o evaluar distintas opciones.

Tareas a realizar para la siguiente semana​

  • Asegurar que la retrospectiva de mitad de sprint ocupe entre el 40% y 50% de la presentación.
  • Mostrar el prototipo actual y su estado de desarrollo.
  • Realizar seguimiento a lo dicho en el Commitment Agreement.
  • Hacer seguimiento de la competencia y actualizar información si es necesario.
  • Explicar explícitamente si hay que reestimar la planificación y justificar los cambios.
  • Mostrar un "reloj de avance" del proyecto, indicando en qué punto de la planificación estamos y cuántas horas se han invertido respecto al total.
  • Mantener la planificación viva y reaccionar a cambios si es necesario.
  • Documentar cómo se está midiendo la productividad y las horas trabajadas.
  • Sacar métricas generales de productividad a partir de estadísticas de Git, pero sin usarlas como argumento absoluto.
  • Mostrar cómo se han resuelto problemas y actualizar el plan de riesgos en función de ello.
  • Explicar la gestión de los usuarios piloto y cómo se planifica la comunicación con ellos.
  • Asegurar que en la documentación de uso de ia se incluyan los prompts utilizados.

Semana 4​

Feedback relacionado con la presentación​

  • Se incluyen elementos no requeridos en el guion (DAFO, BMC, etc.), lo que genera rapidez en la exposición.
  • Si no está en el guion, debe eliminarse.
  • Las llaves ocupan demasiado espacio y dificultan la comprensión; se sugiere reemplazarlas por una tabla con unidades claras y datos digeribles.
  • Números de página demasiado pequeños.
  • Tablas con problemas deben aclarar la terminología (riesgos y problemas no deben mezclarse). Uso inconsistente del idioma (se recomienda unificar en inglés o español).
  • Demasiado contenido textual, se necesitan más elementos visuales.
  • La última diapositiva debe ser la landing page.

Feedback relacionado con el desarrollo del proyecto​

  • No se entiende qué significa que una tarea esté "empezada"; se recomienda indicar el porcentaje de avance.
  • No solo globalizar el porcentaje de progreso del proyecto si se está en un sprint específico, enfocarse tambien en el sprint actual.
  • Excesivo detalle en costos de personal; se recomienda resumir y alinear la información en una tabla.

Tareas a realizar para la siguiente semana​

  • Incluir gráficos subtitulados para una mejor comprensión del progreso individual.

  • Asegurar que el informe refleje un reparto equitativo de horas trabajadas.

  • El report debe contener el mismo contenido que la base de conocimiento, no solo un enlace.

  • Implementar un buscador en Docusaurus para facilitar la navegación.

  • Toda la documentación debe ser editable en formato Markdown (.md), evitando PDF.

  • Crear una guía de revisión del software como documento nuevo.

  • Facilitar la consulta del software mediante casos de uso y expectativas para el próximo día.

  • Explicación clara de qué ha pasado en el Sprint 1.

  • Detalles sobre el funcionamiento de la aplicación (parte más estable del proyecto).

  • Estructura de la Presentación:​

    Introducción (15-20%)

    • Explicación del modelo de negocio y elevator pitch (1 min).
    • Análisis de competidores enfocado en diferenciación del nicho.
    • Análisis detallado de CAPEX, OPEX y costes, asegurando claridad en los números.
    • Estimaciones de costes e ingresos a corto y largo plazo, incluyendo un gráfico ilustrativo.
    • Breve presentación del equipo (sin enfoque en conocimientos técnicos).

    Demo de Resultados (15%)

    • Demostración del prototipo desplegado con casos de uso clave.

    Retrospectiva Completa (40-50%)

    • Evaluación del rendimiento del equipo.
    • Medición de calidad del trabajo realizado hasta ahora.
    • Análisis de tiempo invertido y posición actual en relación al total del proyecto.

    Gestión de Usuarios Piloto (10%-15%)

    • Presentación de los números finales de compromiso de los usuarios.
    • Plan de acción para el final del sprint.

    Planificación de los Próximos Sprints (15%)

    • Estimación concreta del Sprint 2.
    • Objetivos de mitad y final de sprint.
    • Planificación y estimación del desarrollo restante.

    Final

    • Slide final con landing page, QR y URL bien visibles.

Semana 5​

Feedback relacionado con la presentación​

  • Evitar demostraciones en directo, es mejor llevarlas preparadas.
  • Colocar comentarios y enlaces al final, no en medio de la presentación.
  • Usar fondos que garanticen buena legibilidad (evitar textos oscuros sobre fondos oscuros).
  • Presentar solo la información esencial para evitar sobrecarga de datos.
  • Evitar términos vagos como "motivos variados"; especificar si son personales o de diversa índole.

Feedback relacionado con el desarrollo del proyecto​

  • Considerar el uso de pulseras de actividad.
  • Tener en cuenta restricciones de batería y ahorro de energía.
  • Añadir problemas imprevistos al análisis de riesgos.
  • Consolidar métricas de productividad, explicando su aplicación y ponderación.
  • Evaluar la evolución de los sistemas.
  • No dar demasiado peso a la valoración individual; consolidar métricas grupales y definir el resultado final de la evaluación.
  • El diagrama de Gantt en la planificación del sprint requiere demasiado esfuerzo cognitivo y visual.
  • Buen uso de la IA, seguir aplicándolo.
  • Cuidado con el coste de los despliegues
  • Falta la automatización de la medición de la calidad del código
  • No hacéis un uso inteligente de la tecnología: auth 0, login social. No ser artesanos de la tecnología, si no lo vas a hacer mejor, buscar formas de hacerlo
  • Reducir el tiempo general de la introducción

Tareas a realizar para la siguiente semana​

  1. Presentación de Impacto y Marketing
    • Elaborar una presentación más orientada a ventas e impacto.
    • Crear un storyboard para cada tipo de usuario (clientes, usuarios, inversores).
    • Diseñar el esquema visual estilo cómic con muñecos de palo.
    • Definir el guión visual de la historia que vamos a contar.
  2. Impacto Legal del Proyecto
    • Analizar licencias, protección de datos (RGPD) y otros requisitos legales.
    • Identificar implementaciones necesarias en términos de cumplimiento legal.
    • Determinar costos legales y la posible necesidad de un manager legal.
  3. Gastos y Finanzas
    • Realizar estimaciones de gastos con escenarios pesimista y optimista.
    • Definir distintas proyecciones y puntos de equilibrio.
    • Evaluar costos legales y otras inversiones necesarias.
  4. Equipo
    • Revisar y consolidar la estructura del equipo.
    • Definir roles y responsabilidades.
  5. Demo y Desarrollo
    • Preparar una demo de lo que se tenga desarrollado hasta el momento.
    • Identificar principalmete los casos de uso core y los incrementos en el desarrollo.
  6. Análisis de Calidad del Código
    • Realizar retrospectiva de mitad de sprint.
    • Evaluar la calidad del código con herramientas como SonarQube.
  7. Gestión de Usuarios Piloto
    • Monitorear la tasa de abandono y el seguimiento de usuarios piloto.
  8. Planificación y Objetivos del Sprint
    • Definir metas claras para el final del sprint.
    • Implementar pagos reales con cuentas sandbox para probar la monetización para final del sprint.

Semana 6​

Feedback relacionado con la presentación​

  • La presentación inicial necesita más energía y un "killer opener" con storytelling para captar la atención desde el principio.
  • Las transiciones son muy lentas y el último tercio se presenta demasiado rápido.
  • Dirigirse a personas interesadas en geocaching, pensando en perfiles generales y nichos específicos. Identificar posibles aficiones de los usuarios (senderismo, turismo) y destacar cómo el proyecto promueve una actividad saludable.
  • Los storyboards deben conectar emocionalmente y mostrar interacciones reales del producto.
  • El storyboard de inversores debe incluir datos financieros reales y expectativas de ganancias.
  • En lugar de riesgos, destacar problemas específicos y cómo se van a abordar, con medidas claras y resultados verificables.
  • Mejorar las diapositivas de problemas y el análisis de competidores con metáforas visuales y gráficas más claras.
  • Añadir fotos del equipo y mostrar gráficos de evolución del código y rendimiento del equipo.
  • Aclarar casos de uso en los videos y revisar la coherencia del storytelling.
  • Incluir ejemplos gráficos y más detalles específicos en el análisis de competidores y modelos de negocio.

Feedback relacionado con el desarrollo del proyecto​

  • Asegurarse de que todas las soluciones a problemas estén bien definidas y se expliquen con métricas claras para evaluar su efectividad.
  • Incluir la opción de que el usuario pueda solicitar el borrado de datos para cumplir con el GDPR y mostrar gráficos de PSG2 para la seguridad del sistema.
  • Revisar el estilo de código, compartir configuraciones de entornos y mostrar gráficamente la evolución del código (Codacy).
  • Incluir los riesgos identificados previamente y explicar cómo se gestionarán.
  • Integrar botones claros para acceder a funciones premium y el plan premium cuando se intenta realizar una acción restringida.

Tareas a realizar para la siguiente semana​

  1. Compromiso y aceptación de CA:

    • Garantizar que los usuarios comprenden y aceptan el Compromiso de Aceptación (CA).
    • Guardar evidencia legal de que el usuario ha leído y aceptado el CA.

  2. Storyboard:

    • Crear un storyboard para cada actor relevante y uno específico para el inversor.

  3. Condiciones y cláusulas:

    • Evitar cláusulas abusivas en los términos de servicio.
    • Incluir una descripción clara de lo que ofrece el servicio.

  4. SLAs y certificaciones:

    • Definir los acuerdos de nivel de servicio (SLA) y evaluar qué sucede si proveedores externos (como los de mapas) fallan.
    • Verificar y validar los niveles de certificación.

  5. Costes y proyección:

    • Crear gráficas de proyección de costes a dos años a partir del WPL.

  6. Retrospectiva del Sprint 2:

    • Dedicación del 50% de la presentación.
    • Mostrar un gráfico matriz rendimiento/esfuerzo (con ejes de rendimiento y esfuerzo), destacando la media grupal y considerando las 20 horas.

  7. Planificación Sprint 3:

    • Validar aspectos de seguridad: correos electrónicos reales, tarjetas de crédito y otros datos validables.
    • Evitar trabajar solo en el 'happy path' y considerar posibles errores.
    • Confirmar los pagos reales y su seguridad.

  8. Feedback y comunicación:

    • Aplicar píldoras de feedback para mejorar el flujo de trabajo.
    • Para problemas de comunicación, utilizar calendarios compartidos.

  9. Uso de la IA:

    • Analizar el impacto del uso de la IA en el proyecto.
    • Identificar lecciones aprendidas y posibles alucinaciones (errores) de la IA.

  10. Changelog:

  • Crear un changelog automático para registrar cambios y novedades relevantes.
  1. Recortes en el alcance: Si no se pueden aplicar todos los cambios debido a limitaciones de tiempo, documentar lo pendiente para realizarlo en el Sprint 4.

Semana 7​

Feedback relacionado con la presentación​

  • Inicio mejorable: más claridad y originalidad, sin depender de “magia”.
  • Los storyboards deben ser independientes; el inversor solo necesita ver inversión y retorno.
  • Falta un análisis retrospectivo claro para mostrar la evolución del proyecto.
  • Pricing está en la demo pero no en las diapositivas y la comparativa de funcionalidades no está incluida en la presentación.
  • Algunos valores no se entienden bien (cómo fueron calculados).
  • Número de página se pierde en varias diapositivas.
  • Evitar confusión con elementos visuales en diferentes sentidos (horario/antihorario).
  • Incluir zoom en la demo para mayor claridad.
  • “Killer opener” ligado al storyboard para captar la atención y seguir un hilo argumental
  • Cada storyboard tiene que ser separado

Feedback relacionado con el desarrollo del proyecto​

  • 100 €/mes por empresa es un precio elevado para lo que se ofrece.
  • No puede haber un coste fijo desde el inicio; debe haber crecimiento gradual.
  • Los mapas colaborativos tienen mayor potencial, enfocarse en eso.
  • Código: más allá de explicar métricas, enfocarse en su calidad.
  • Lo importante no es solo el tiempo utilizado sino el retraso acumulado.
  • Incluir gráficos burndown y burnup de GitHub.
  • Mejorar el diseño del frontend de pagos.
  • Especificar claramente la licencia del software.
  • Incluir métricas de TTO y TTR (tiempo de respuesta y resolución).

Tareas a realizar para la siguiente semana​

  1. Conversión de Storyboard en Anuncio

    • Transformar un storyboard en un anuncio realista.

  2. Plan de Pruebas para el World Project Launch (WPL)

    • Definir y documentar el plan de prueba.
    • Incluir métricas y umbrales para evaluar la efectividad de la solución.

  3. Demo: Aspectos Claves a Destacar

    • Mejoras en la experiencia del usuario basadas en feedback de usuarios piloto.
    • Cuestiones regulatorias relevantes.

  4. Cobertura de Tests

    • Aumentar la cobertura de pruebas al 50% de cara a que sea 70%.

  5. Feedback de Usuarios Piloto

    • Priorizar los comentarios según su impacto y relevancia.
    • Definir métricas para evaluar qué feedback representa necesidades reales.

  6. Resolución de Problemas y Evaluación de Soluciones

    • Mantener separados los problemas de sus soluciones.
    • Estudiar la efectividad de las soluciones implementadas.
    • Apoyarse en datos para medir la resolución de problemas.

  7. Gestón de Dependencias de APIs Externas

    • Definir sistemas de respaldo para evitar bloqueos si una API externa falla.

  8. Planificación Preliminar de la Siguiente Fase

    • Enfocarse en la estrategia de marketing.

Semana 8​

Feedback relacionado con la presentación​

  • Debe especificar mejor el mensaje y aprovechar el concepto central de la app cambiando de lugar constantemente, por ejemplo.
  • Faltan límites claros de inversión (máximo 49% para no perder control).
  • Proponer paquetes de inversión definidos en storyboard de inversores
  • Demo es demasiado rápida, necesita más zoom y mejor ritmo.
  • Indicar en todo momento quién está usando la app durante la demo.
  • Demo cambiar las imágenes de los logros (no se entendieron o no cargaron bien).
  • En la proyección financiera evitar dos ejes
  • En productividad: en los segmentos poner gradientes.
  • Faltó indicar el número de usuarios actuales o potenciales.

Feedback relacionado con el desarrollo del proyecto​

  • Usar partnerships como táctica para atraer usuarios.
  • Incentivar la retroalimentación mediante recompensas (gamificación + viralidad).
  • Priorizar el feedback de fallos: detectar y resolver errores rápidamente.
  • En el cronograma, mostrar en la segunda semana el porcentaje de avance de tareas.
  • Explicar cómo cambiar los costes para anuncios puede impactar los beneficios.

Tareas a realizar para la siguiente semana​

Anuncios y introducion​

  • Crear un nuevo anuncio en vídeo basado en el segundo storyboard.
    • Si da tiempo, mostrar ambos anuncios (el nuevo y el anterior), pero no es obligatorio enseñar los dos.
    • Intentar que duren poco para mantener la atención.
  • Preparar una introducción de 2-3 minutos:
    • Killer opener y/o elevator pitch.
    • Análisis breve de competidores.

Marketing y tracción en el mercado​

  • Eliminar sección de customer agreement de la presentación.
  • Preparar un análisis preliminar de marketing:
    • Estrategia para ganar clientes.
    • Gestión de la tracción inicial en el mercado.
  • Definir la distribución de responsabilidades dentro del equipo de marketing:
    • Roles en redes sociales, campañas automáticas, y community manager.
  • Actualizar el TCO (Total Cost of Ownership):
    • Incluir costes actualizados de marketing.
    • Añadir el número de usuarios actuales o proyectados.

Producto y pruebas​

  • Preparar una demo funcional del producto.
  • Definir un plan de pruebas post-lanzamiento:
    • Qué módulos serán probados.
    • Tipo de pruebas (unitarias, funcionales, etc).

Equipo y retrospectiva​

  • Actualizar los roles del equipo, especialmente en marketing.
  • Preparar una retrospectiva del trabajo hasta ahora.

Semana 9​

Feedback relacionado con la presentación​

  • Mejorar la iluminación del video para mayor calidad visual en el video de inversores
  • En el video de inversoresUsar overlays visuales (gráficos, cifras) para mostrar fuentes de ingresos y datos que respalden el negocio con datos reales para generar confianza y credibilidad.
  • Resaltar el impacto en salud, explicar de forma clara cómo la app ayuda en este ámbito.
  • Aportar datos del mercado y cifras que validen el tamaño de la oportunidad.
  • Conocer bien las protopersonas (clientes objetivo) y reflejarlo de manera explícita en el pitch.
  • Alinear cifras de ingresos o mercado con esas protopersonas para mayor coherencia.
  • Analizar si existen leyes regionales que podrían afectar el uso o despliegue de la app.
  • Tener cuidado con zoom in / zoom out, puede marear al usuario.

Feedback relacionado con el desarrollo del proyecto​

  • Mencionar los bugs encontrados durante el testing.
  • Identificar y explicar problemas concretos que surgieron durante el desarrollo.
  • Usar métricas como burn-up/down charts.
  • Dar estimaciones de completitud de la app (porcentaje, horas trabajadas, costos).
  • Incluir gráficas por entregable mostrando el trabajo realizado por cada integrante del equipo.

Tareas a realizar para la siguiente semana​

PRESENTACIÓN 1: World Project Launch (duración: 10 minutos)​

1. Estructura general del pitch:​
  • Killer opener (1 minuto): Apertura fuerte y memorable.
  • Anuncio orientado al cliente (1 minuto): Qué problema resolvemos, cómo cambia la vida del usuario.
  • Qué hace el proyecto (sin explicar cómo se construyó):
  • Historia coherente y realista u optimista.
  • Demostración del producto (demo basada en un recorrido narrativo).
  • Competencia:
  • Quiénes son los competidores actuales.
  • En qué nos diferenciamos.
  • Equipo (opcional o breve):
  • Quiénes están detrás del proyecto.
  • Estructura organizativa (si aporta valor).
  • Sostenibilidad y rentabilidad:
  • Pricing plan.
  • Costes principales.
  • Paquetes de inversión (breve anuncio, 1 minuto máx).
  • Call to action final:
  • Enlace a la landing page.
  • Enlace al producto/prototipo.

📊 PRESENTACIÓN 2: Go-to-Market & Marketing Plan (duración: 5 minutos)​

1. Segmentación del público:​
  • Modelo de segmentación de audiencia.
  • Crear mínimo 2 protopersonas (buyer personas).
2. Visibilidad y adquisición de usuarios:​
  • Estrategia SEO:
  • Palabras clave principales.
  • Redes sociales:
  • Segmentación por persona.
  • Plan de publicaciones.
  • Campaña de contenidos previa al lanzamiento (soft-launch).
  • Campaña de lanzamiento clara:
  • Acciones para ganar visibilidad y tracción.
  • Posibles aliados o partnerships para amplificación.
3. Community Management:​
  • Definir rol, objetivos e impacto.
  • Plan de publicaciones con intención clara.
  • Sistema de seguimiento y mejora del plan.
4. Costes y herramientas:​
  • Desglose de costes de marketing.
  • Anuncios dirigidos (targeted ads).
  • Actualización constante de la landing page.
  • Uso de IA para apoyo en marketing (por ejemplo: generación de contenido, análisis de rendimiento, etc.).

Semana 10​

Feedback relacionado con la presentación​

  • Faltó un "killer opener" que captara la atención desde el principio.
  • La demo fue muy rápida y la música de fondo resultó distractora.
  • Faltó un flujo narrativo más claro, como resumir las principales características de MapYourWorld antes de la demo.
  • Se mencionaron competidores pero no se destacó claramente el diferencial de la aplicación en base al contexto en el que se mueven. Se sugiere crear una fila adicional para enfatizar en qué se centran otros competidores y qué nos diferencia.
  • Los paquetes de inversión presentados fueron percibidos como demasiado pretenciosos.
  • Se recomienda ajustar los paquetes para permitir microinversiones (máximo 10 %) pensando en un público tipo Kickstarter.

Feedback relacionado con el desarrollo del proyecto​

  • Variación de gastos semana a semana (semana 29 y 30) parece aleatoria, falta explicación o justificación.
  • Se necesita concretar más la planificación de publicaciones en redes sociales.
  • Falta establecer métricas claras como porcentaje de impresiones que deben convertirse en usuarios y cómo reaccionar si no se alcanza.
  • Incluir coste por adquisición (CPA), coste por instalación y análisis del funnel de conversión (clics vs. instalaciones).
  • Considerar también herramientas de marketing que impliquen costes y su justificación.
  • Definir el peso visual de las características principales y evitar sombras en los iconos, ya que afectan negativamente al diseño.
  • Especificar qué palabras clave se optimizaron y aportar datos.
  • Usar herramientas para medir y gestionar el crecimiento, recopilando métricas relevantes.

Tareas a realizar para la siguiente semana​

  • Aplicar el feedback
  • Cambiar el enfoque de un plan de marketing sobre el papel a un plan de marketing en marcha

Semana 11​

Feedback relacionado con la presentación​

  • Crear un killer opener atractivo y conectarlo con el anuncio al cliente y la demo, para que todo cuente una historia coherente.
  • Mejorar la parte inicial de la presentación (quiénes somos, qué hacemos, competidores, demo) para que tenga más claridad y cohesión.
  • La diapositiva 21 fue explicada demasiado rápido; necesita más desarrollo.
  • La diapositiva 29 es demasiado teórica y no aporta valor en la presentación actual.
  • El anuncio dirigido al cliente necesita una mejora en la voz de la frase final, y hay que nivelar el audio de los 3 videos.
  • El anuncio a inversores no debe centrarse en la cifra de 40k, sino en puntos de equilibrio y retorno de inversión (ROI).
  • Primero se deben explicar las fuentes de beneficio antes de hablar del balance.
  • Especificar claramente en qué se va a gastar el dinero que se pide a los inversores (por ejemplo, acciones concretas de marketing y sus efectos).
  • En la nueva presentación no es necesario detallar la estructura del equipo a nivel de roles, ya que no aporta valor en esta fase.

Feedback relacionado con el desarrollo del proyecto​

  • Repensar los paquetes de inversión: definir cuánto vale cada acción y qué beneficios obtienes al alcanzar ciertos niveles de inversión.
  • En el anuncio del CEO, enfocar el discurso en palabras clave que buscarían las protopersonas.

Tareas a realizar para la siguiente semana​

  • Defensa 16 de mayo presentacion de 5 min con los apartados: que ha hecho cada individuo, que problemas se han encontrado y que soluciones se han dado, como se ha hecho esa evaluación de la nota final.
  • 12:30 a 5:30 (3:30-5:30 turno de tarde) viernes 23 de mayo dia de presentación final.
  • Jueves 22 de mayo ensayar presentación en salón de actos de 13:30 hasta las 16:30
  • Martes 13 de mayo slide de anuncio en la etsii.

Grupo 8 - Infanten​

Semana 1​

Feedback relacionado con la presentación​

  • Buena presentación, pero falta el logo.
  • Utilizar una plantilla más coherente y no invasiva.
  • Describir la aplicación de forma concisa: "App para la gestión de viajes en grupo".
  • Tablas comparativas deben estar incluidas si se mencionan.

Feedback relacionado con el desarrollo del proyecto​

  • Modelo de negocio debe estar más centrado y especificado.
  • Identificar claramente el MVP, demasiadas funcionalidades.
  • Definir protopersonas para caracterizar los usuarios potenciales.
  • Asegurar coherencia entre las funcionalidades propuestas y el tiempo disponible.
  • Si se integran aplicaciones existentes, debe aportar valor adicional.

Semana 2​

Feedback relacionado con la presentación​

  • Evitar el uso de "Lorem Ipsum" en los mockups, utilizar ejemplos reales para mayor claridad.
  • Asegurar que la información clave esté bien estructurada y visualmente clara.
  • Mejorar la forma de presentar a la competencia antes de explicar el modelo de negocio.
  • Explicar claramente la diferencia principal frente a la competencia.

Feedback relacionado con el desarrollo del proyecto​

  • Profundizar en el modelo de monetización, identificando quién paga realmente y cómo.
  • Justificar la estructura de costes e incluir costes sociales con datos de referencia (ej. GetManfred).
  • Explorar más a fondo la competencia y analizar sus métodos de cobro.
  • Identificar mejor el uso de IA, tecnología y compromiso con el usuario (commitment agreement).

Semana 3​

Feedback relacionado con la presentación​

  • Falta una descripción clara y ambiciosa del producto antes de hablar del MVP.
  • El orden del contenido no es intuitivo, es desordenado y se presentan riesgos antes de contextualizar el producto.
  • La tipografía no es legible, debe mejorarse.
  • Existen diferencias de tamaño y peso en los textos que generan desorientación.
  • Información importante no debe dejarse fuera de la presentación esperando que se pregunte después.
  • El precio del plan premium debe comentarse antes en la presentación, no en una diapositiva fuera de contexto.

Feedback relacionado con el desarrollo del proyecto​

  • Definir correctamente el producto antes de saltar al MVP.
  • Incluir una tabla de competidores bien explicada.
  • Evaluar correctamente ingresos y costes (beneficio = ingresos - costes).
  • No trabajar con precios sin IVA.
  • Considerar el cálculo de ramen survivability (punto de equilibrio financiero).
  • Explicar mejor la estructura de costos y especificar cálculos realizados.
  • Agregar elementos faltantes: commitment agreement, ALN, landing page, uso de IA.
  • No abordar riesgos técnicos o legales sin haber explicado antes las decisiones tomadas.

Semana 4​

Feedback relacionado con la presentación​

  • Es necesario resumir y concentrar la información, especialmente en costos y ganancias. Se debe facilitar la digestión de los datos con tablas y números bien formateados.
  • La tipografía no se ve bien y las diapositivas son densas. Es recomendable usar siglas comprensibles y hacer la información más digerible.
  • El diagrama de Gantt y otros elementos visuales (CV, SV, CPI, SPI) no se ven bien. No basta con capturas de pantalla; deben integrarse correctamente en la presentación.
  • Se debe controlar mejor el ritmo de la presentación, filtrando la información relevante antes de presentarla, no en el último momento.
  • El inicio de la presentación debería generar más conexión con el problema del proyecto, mostrando empatía, especialmente considerando el público objetivo (niños).

Feedback relacionado con el desarrollo del proyecto​

  • No es recomendable limitarse a los usuarios piloto asignados por la asignatura; es necesario hacer el esfuerzo de encontrar más participantes. Además, asignarles roles no tiene sentido.
  • Debe mejorar la presentación de la planificación para que sea comprensible para todos, sin asumir que el público conoce ciertos conceptos.
  • Es clave definir mejor el punto de equilibrio entre costes y beneficios y presentar esta información de manera clara. Además, se debe hablar de retorno por usuario en lugar de ganancias.
  • No se debe incluir contenido solo porque faltó en entregas anteriores; la información debe estar en el momento adecuado según el avance del proyecto.

Semana 5​

Feedback relacionado con la presentación​

  • Generar más impacto en menos tiempo, especialmente en el elevator pitch.
  • Buena estética, pero algunos gráficos no aportan y pueden distraer. Se recomienda resaltar información clave con colores llamativos (ej. rojo).
  • No usar lorem ipsum ni datos genéricos, sino información realista.
  • Incluir personas reales en la demo para mejorar la conexión con el usuario.
  • No incluir registro ni login para agilizar la experiencia.
  • Estructura de la presentación es correcta, pero necesita mayor atractivo y efectividad en la introducción.

Feedback relacionado con el desarrollo del proyecto​

  • Estructura del equipo es actualmente muy piramidal, evaluar si realmente es funcional o si se puede hacer más plana.
  • Implementar herramientas como SonarQube para medir deuda técnica y evolución del código.
  • Configurar sistemas que rechacen pull requests de baja calidad.
  • Pensar en diseñar la app para que pueda usarse con una sola mano.
  • Usuarios piloto: Buscar más testers reales para validar el producto.

Semana 6​

Feedback relacionado con la presentación​

  • Evitar hablar en tercera persona en los storyboards dirigidos a inversores.
  • Incluir cifras claras y presentarlas en gráficas para facilitar la comprensión.
  • Asegurarse de que el nombre "Infanten" no aparezca sin contexto en los storyboards.
  • Saltarse el "meta anuncio" para mantener la atención en el contenido principal.
  • Homogeneizar las fotos del equipo para una imagen más profesional.
  • Mejorar las gráficas de número de horas para que sean más claras y efectivas.
  • Reducir el nivel de detalle en la sección de impacto legal.
  • Evitar que el producto aparezca "mágicamente" en la narrativa; debe haber una introducción clara.

Feedback relacionado con el desarrollo del proyecto​

  • Evaluar el coste de mantenimiento futuro para contratar nutricionistas como consultores.
  • Adaptar las funcionalidades del producto a las capacidades y servicios de un dietista/nutricionista real.
  • Solucionar el problema del 0% de testing en el código, ya que es preocupante.
  • Resolver los problemas con el despliegue continuo.
  • Analizar el atractivo del contenido premium, especialmente las recetas para bebés, ya que parecen ser el principal incentivo para pagar.

Semana 7​

Feedback sobre la Presentación​

  • Usar más metáforas visuales y menos texto (icono + palabra).
  • Evitar redundancias: si algo es claro, no repetirlo.
  • No mantener un tono monótono en la presentación.
  • En el storyboard para inversores, reducir la cantidad de información.
  • Resumir números, evitar demasiados ceros, usar "k" cuando sea posible.
  • Considerar que la audiencia deja de escuchar si hay demasiada información.

Feedback sobre el Desarrollo del Proyecto​

  • Priorizar el feedback de usuarios piloto.
  • Asegurar que el MVP no duplique contenido.
  • Desglosar el análisis de calidad del código, en lugar de un resumen sintético:
    • Explicar qué, por qué y cómo se ha mejorado.
    • Mostrar puntos de mejora y progresión con comparaciones previas.

Semana 8​

Feedback relacionado con la presentación​

  • Hacer más pausas al presentar.
  • Acortar el tiempo que se dedica al MVP durante la presentación.
  • Evitar incluir el anuncio dentro del storyboard; el anuncio debe sustituirlo.
  • El “killer opener” debe enfocarse más directamente en lo que hace la app.
  • Comenzar con algo que tenga 100% que ver con el producto.
  • No usar imágenes que son como "lorem ipsum"; deben ser fotos reales de las recetas.
  • En la demo, destacar mejoras reales de UI/UX basadas en feedback de usuarios piloto.
  • Asegurarse de que las gráficas tengan leyendas claras, especialmente para las horas.
  • Los anuncios deben ser autocontenidos, contar su historia por sí mismos.

Feedback relacionado con el desarrollo del proyecto​

  • Explicar mejor cómo se realiza el “matching” entre recetas y bebés.
  • Incluir lo de Amazon en el modelo de negocio.
  • Dividir la inversión necesaria en paquetes que prometan retorno.
  • Enfocar más en problemas de comunicación que se puedan medir y seguir en el tiempo.
  • Los problemas técnicos no interesa tanto medir en su evolución; priorizar los no técnicos.

Semana 9​

Feedback relacionado con la presentación​

  • Claridad y ritmo: Se solapan frases entre sí, lo que dificulta la comprensión. Se recomienda ensayar más y respetar pausas.
  • Uso de texto vs elementos visuales: Hay demasiado texto; se sugiere incluir más metáforas visuales y reducir el contenido escrito, especialmente en las diapositivas de usuarios piloto.
  • Datos y cifras:
    • Abreviar cifras (usar “k” o “m”).
    • Usar estadísticas reales y citar las fuentes.
  • Diapositivas específicas:
    • Recortar el anuncio de “gratis” y unirlo con el del “premium”.
    • Separar con una metáfora visual a los que suben y bajan en la tabla de rendimiento.
  • Título inadecuado: El análisis de rendimiento en realidad muestra problemas; cambiar el título a algo más acorde.

Feedback relacionado con el desarrollo del proyecto​

  • Población objetivo: Refinar mejor el target con cifras concretas y reales.
  • Métrica de rendimiento: Se sigue utilizando una métrica que limita el rendimiento a 10, lo cual puede estar afectando negativamente los resultados.

Semana 10​

Feedback relacionado con la presentación​

  • La presentación terminó demasiado rápido; podrían gestionar mejor el tiempo.
  • El hilo argumental de la presentación necesita mejorar para ser más claro y coherente.
  • El anuncio debería mostrar comida o problemas relacionados con la comida, para reforzar el mensaje.
  • La demo fue algo breve; podría apoyarse más en explicar las características del producto.
  • En el anuncio dirigido a inversores, falta incluir las opciones de inversión.
  • En el calendario de publicaciones, la iconografía debería ser más clara para facilitar la comprensión.

Feedback relacionado con el desarrollo del proyecto​

  • Sería mejor agrupar todos los costes en un único apartado para mayor claridad.

Semana 11​

Feedback relacionado con la presentación​

  • Narración en la demo: Si no hay audio en la demo, es necesario narrarla en directo para facilitar la comprensión.
  • Diapositiva 14: Ocupó demasiado tiempo, habría que agilizarla o resumirla.
  • Gráficos: En lugar de mostrar datos en diapositivas separadas, conviene usar una gráfica de evolución para facilitar la comprensión visual y la comparación.

Feedback relacionado con el desarrollo del proyecto​

  • Modelo de ingresos: El término "freemium" no es del todo preciso; sería más adecuado hablar de usuarios premium como fuente de ingresos principal.
  • Proyección de usuarios: El objetivo del 14% parece demasiado ambicioso; se recomienda justificarlo mejor o presentar una evolución progresiva más realista.
  • Segmentación de usuarios: Los dos segmentos identificados pueden coincidir en una misma persona; es importante tenerlo en cuenta al definir la estrategia.
  • Protopersonas: Falta información sobre el bebé, lo cual es relevante si es un usuario o parte clave del contexto de uso.

Grupo 9 - Caronte​

Semana 1​

Feedback relacionado con la presentación​

  • Descripción puede ser más corta y precisa.
  • Estructura de la presentación debe ser más uniforme.
  • Evitar textos innecesarios y mantener diseño limpio.

Feedback relacionado con el desarrollo del proyecto​

  • Asegurar que el MVP es alcanzable en el tiempo disponible.
  • Definir claramente usuarios y clientes en el modelo de negocio.

Semana 2​

Feedback relacionado con la presentación​

  • Explicar primero el propio proyecto antes de analizar la competencia.
  • Mejorar la narrativa de la presentación, evitando cambios abruptos entre secciones.
  • Incluir diagramas UML más visuales y explicativos en lugar de solo esquemáticos.

Feedback relacionado con el desarrollo del proyecto​

  • Transformar los anuncios de esquelas en un servicio más personalizable e interactivo.
  • Evaluar aspectos de seguridad en el flujo del servicio.
  • Incluir análisis sobre servicios pre y post-mortem, identificando oportunidades de innovación.
  • Explorar estrategias disruptivas para posicionar el producto en el mercado.
  • Mejorar la identificación de los canales de distribución actuales.

Semana 3​

Feedback relacionado con la presentación​

  • La información debe estar estructurada y explicada, no simplemente volcada en bruto. Cada diapositiva debe ser fácilmente comprensible.
  • Mejorar la tipografía, evitar que las flechas atraviesen todo el lienzo y hacer las imágenes más homogéneas.
  • La "nube de competidores" no aporta si no está organizada y explicada.
  • El salto del video a la presentación es confuso y debe hacerse más limpio.
  • Business Model Canvas: Cuidado con la disposición de las flechas para que el flujo sea claro.

Feedback relacionado con el desarrollo del proyecto​

  • Hay demasiada dependencia externa, lo que puede ser un riesgo.
  • Protopersonas vs. usuario piloto, una protopersona no da feedback real, hay que tener cuidado con cómo se presentan los datos y términos.

Semana 4​

Feedback relacionado con la presentación​

  • El orden de la presentación no es adecuado: primero se debe explicar qué se ofrece antes de hablar de la competencia.
  • Hay confusión con la numeración de las páginas.
  • No se justifica de dónde sale la estimación de clientes.
  • Falta claridad en cómo se venderá el producto y cuándo.
  • No se menciona qué pasa si un usuario se enferma y cómo se justifica.

Feedback relacionado con el desarrollo del proyecto​

  • Los costes a largo plazo no están bien considerados.
  • Se deben incluir costes de soporte técnico y atención al cliente.
  • Se necesita una proyección clara de ingresos, gastos y costes en el tiempo.
  • La idea de un solo pago puede ser viable, pero se debe analizar el riesgo si la empresa desaparece antes que los clientes.
  • El 1% de la población española puede parecer poco, pero hay que considerar la disposición real de los clientes potenciales.
  • El público más probable son personas con hijos, aunque técnicamente todos puedan ser clientes.
  • Se deben explorar todos los segmentos del mercado, pero también considerar si es una moda pasajera.
  • Puede haber fricción con los seguros de decesos; si se cobra un pago constante, se debe ofrecer un servicio constante.
  • El factor tiempo es fundamental y debe ser analizado con detalle.
  • Es importante evaluar tendencias y modas para determinar la viabilidad a largo plazo.
  • No se han considerado los costes asociados a enfermedades.
  • La idea de "3 usuarios piloto por persona" debe ser revisada para entender su impacto real en la estrategia.

Semana 5​

Feedback relacionado con la presentación​

  • No aplicar todo el feedback sin un análisis crítico previo.
  • Separar en la presentación el proyecto y el equipo de los problemas que ha habido.
  • Diferenciar claramente entre personas y roles. Si alguien está en más de dos equipos, se habla de roles, no de departamentos.
  • Buscar otra forma de mostrar el número de miembros por equipo.
  • En la gráfica de monetización, usar una curva acumulativa de beneficios y marcar claramente el punto donde se cruza el 0 (inicio de beneficios).

Feedback relacionado con el desarrollo del proyecto​

  • Las incertidumbres tecnológicas deben resolverse lo antes posible mediante pruebas de concepto.
  • En todo proyecto, los aspectos más problemáticos deben abordarse primero.
  • Horas trabajadas:Marcar la línea de los mínimos esperados, no mostrar horas totales, sino valores más útiles como la media, no usar decimales en las horas.
  • La calidad del código debe garantizarse con pruebas funcionales y herramientas estáticas de análisis.
  • Un 90% de avance suele significar que una tarea está hecha pero no probada.
  • La sección de "problemas" no debe estar dentro de la parte del equipo.

Semana 6​

Feedback relacionado con la presentación​

  • El "killer opener" está bien, pero se sugiere añadir un apoyo visual más emocional.
  • Storyboard mostrarlo claramente cuando se hable del anuncio y añadir información de precios.
  • Usar "gastos" en lugar de "pérdidas".
  • Se recomienda hacer demostraciones grabadas para evitar fallos de latencia y asegurar claridad en los casos de uso probados.
  • No mezclar información de algunos apartados con los cambios hechos a partir de comentarios de usuarios piloto.
  • Mejorar la gráfica del product backlog separando las categorías de estado de cada tarea.

Feedback relacionado con el desarrollo del proyecto​

  • Los datos de usuarios que abandonan deben anonimizarse, pero no borrarse para análisis estadísticos.
  • Evaluar la efectividad de las soluciones implementadas.
  • Reducir el alcance de tareas no esenciales para ajustar las horas estimadas.
  • Aprovechar la tecnología para optimizar recursos y reducir costes.
  • Utilizar Codacy para evaluar la calidad del código a lo largo del tiempo y medir el rendimiento individual de forma anónima.

Semana 7​

Feedback sobre la Presentación​

  • Inicio efectivo: Mejorar el "killer opening" aprovechando ideas del storyboard.
  • Orden de la presentación: Actualmente confuso; sugerencia de estructura:
    1. Elevator pitch (ya está bien logrado).
    2. Storyboards.
    3. Comparativa con competidores (remarcando mejor las diferencias).
    4. Demo (que actualmente no se ve bien).
  • Customer Agreement: Aclarar cómo se han evitado cláusulas abusivas.

Feedback sobre el Desarrollo del Proyecto​

  • Evaluación del código: Incluir el diferencial de rendimiento.
  • Copilot: Nueva funcionalidad para pull requests, considerar su uso.
  • Priorización del feedback: Mostrar cómo se priorizan tareas derivadas de los comentarios de los usuarios piloto.
  • Seguimiento del feedback: ¿Caronte se pone en contacto con quienes sugieren mejoras?

Semana 8​

Feedback relacionado con la presentación​

  • Faltan opciones de inversión detalladas con sus respectivos retornos y probabilidades.
  • Se debe usar la marca y colores corporativos en toda la aplicación y presentación.
  • Evitar el uso de términos contradictorios al explicar conceptos técnicos como la "deuda técnica".
  • Se sugiere considerar cómo se va a captar usuarios tras el despliegue de la aplicación.

Feedback relacionado con el desarrollo del proyecto​

  • Añadir un nivel más de categorización al feedback, incluyendo qué comentarios se van a ignorar y por qué (por ejemplo: contradictorios, fuera del dominio del proyecto, etc.).
  • Incorporar una métrica que permita ver el acumulado de horas trabajadas, comparándolo con la media del resto del proyecto para identificar si hay desviaciones o retrasos sistemáticos.

Semana 9​

Feedback relacionado con la presentación​

  • Cuidado con lo que se comunica: No digáis que habéis completado todo si realmente se ha recortado el alcance.
  • Demo: Se sugiere acortarla y centrarse en lo fundamental.
  • Anuncio de la empresa: Es muy genérico y no refleja bien la temática (es una floristería sin una sola maceta). Se podría mejorar, pero no eliminar por completo.
  • Gráfica de trabajo (slide 21): No queda claro lo que quiere transmitir.
  • Gráfica del Sprint 4: El salto en la gráfica no tiene sentido y puede generar confusión.

Feedback relacionado con el desarrollo del proyecto​

  • Código duplicado: Hay duplicidad de código, aunque no se cuentan los test en esto.
  • Certificación: No generéis un certificado si no es necesario.

Semana 10​

Feedback relacionado con la presentación​

  • El collage de imágenes inicial es muy heterogéneo y tiene demasiadas cosas; se recomienda eliminarlo.
  • Se sugiere empezar directamente con el video.
  • El concepto del video no se entiende bien y el audio se escucha mal.
  • El apartado "estado civil: trabajando" no es adecuado; debe corregirse porque no es un estado civil.
  • Debe especificarse que el número mencionado corresponde a publicaciones.
  • En la comparación de costes (pesimista vs optimista), es necesario explicar claramente qué significa ser optimista o pesimista.

Feedback relacionado con el desarrollo del proyecto​

  • Los temas de la moral y de la retrospectiva no deben incluirse en esta fase actual, ya que correspondían a una fase anterior del proyecto.

Semana 11​

Feedback relacionado con la presentación​

  • En la demo estabas compitiendo con la musica en el video de inversores quizás darle un tono mas serio menos parodia

Feedback relacionado con el desarrollo del proyecto​

  • En el video de inversores quizás darle un tono mas serio menos parodia

Grupo 10 - Go4Surprise​

Semana 1​

Feedback relacionado con la presentación​

  • Mantener una plantilla visual coherente.
  • Evitar sobrecarga de información en las diapositivas.
  • Incluir logo y definir identidad visual.

Feedback relacionado con el desarrollo del proyecto​

  • Definir claramente el público objetivo.
  • Especificar el MVP con funcionalidades clave bien delimitadas.

Semana 2​

Feedback relacionado con la presentación​

  • Evitar sobrecargar la presentación con demasiada información, hacerla más digerible.
  • Presentar mockups que cuenten una historia en lugar de simples interfaces técnicas.
  • No incluir iconos flotantes innecesarios en diagramas de arquitectura.

Feedback relacionado con el desarrollo del proyecto​

  • Analizar mejor la percepción del valor del producto y cómo afecta la experiencia del usuario.
  • Identificar formas de reducir la carga cognitiva en la toma de decisiones del usuario.
  • Explorar modelos de monetización más concretos y estructurados.
  • Asegurar que los costes de mantenimiento sean viables a largo plazo.

Semana 3​

Feedback relacionado con la presentación​

  • Mejorar la legibilidad de las diapositivas: evitar letras muy pequeñas y diapositivas con exceso de texto.
  • Ajustar el guion de la presentación para mayor claridad y fluidez.
  • En presentaciones con tiempo limitado, evitar el índice y estructurar el contenido como una historia.

Feedback relacionado con el desarrollo del proyecto​

  • Definir bien la escala del proyecto desde el inicio.
  • Asegurar un respaldo económico adecuado para una idea arriesgada.
  • No asumir todo el coste de los beneficios sin una estrategia clara.
  • Considerar alternativas de asignación de recursos.
  • Incluir costes sociales además del coste bruto.
  • Definir bien las unidades temporales en los cálculos de costes.
  • Priorizar volumen de clientes/usuarios para la viabilidad del proyecto.
  • Evaluar si el tiempo de respuesta para la devolución del dinero es suficiente, considerando imprevistos.

Semana 4​

Feedback relacionado con la presentación​

  • El inicio debe ser impactante; eliminar contenido innecesario.
  • No es necesario un índice, la presentación debe fluir naturalmente de un tema a otro.
  • Enfocarse en demostrar que el proyecto es viable y que hay negocio.
  • Destacar la parte económica, mostrando cifras claras.
  • Hablar del equipo: su historia, experiencia y por qué son adecuados para el proyecto.
  • No centrarse en que son los usuarios piloto, sino en cómo se gestionan y el feedback obtenido.
  • La parte de riesgos no es prioritaria; solo mencionar problemas concretos y su resolución.
  • Asegurar que la demo se vea bien y sea efectiva.

Feedback relacionado con el desarrollo del proyecto​

  • Se debe tratar con más seriedad la falta de horas registradas en Clockify, ya que sugiere que algunos miembros no han trabajado.
  • El inicio de sesión no es un caso de uso central, por lo que no debía haberse priorizado en el desarrollo.
  • El registro no es necesario para el modelo de negocio; se debería permitir la compra como invitado.
  • En la gestión de usuarios y problemas, es clave mitigar los inconvenientes que surjan.

Semana 5​

Feedback relacionado con la presentación​

  • El "killer opener" debe ser más entusiasta y cauteloso con preguntas abiertas que asuman respuestas, pueden hacer perder el interés del público.
  • Evitar referencias al alcohol, ya que no es universalmente aceptado.
  • La transición en la estimación de ingresos debe ser más suave, usando "ingresos esperados" en vez de "ingresos medios".
  • La diapositiva de gastos es buena, pero se sugiere mostrar escenarios pesimista, estimado y optimista
  • Evitar mezclar en una sola diapositiva lo que ha ido bien, mal y lo que hay que mejorar; mejor usar tres diapositivas separadas con metáforas visuales.
  • El video se percibe lento.
  • La demo debe centrarse en lo importante: la reserva.
  • Reducir texto y hacer la presentación más visual.

Feedback relacionado con el desarrollo del proyecto​

  • El diagrama de Gantt es útil para secuenciar tareas y visualizar paralelismo, pero no para mostrar todo lo realizado. Se puede usar para incidencias y retrasos.
  • No queda claro si se ha realizado un análisis del feedback de los usuarios piloto.
  • Es importante hacer una mejor categorización y análisis del feedback recibido.
  • El registro y login no son necesarios en la presentación.
  • El equipo full-stack debería definir mejor sus roles para evitar redundancias.

Semana 6​

Feedback relacionado con la presentación​

  • Iniciar de manera efectiva explicando quiénes son sin decir explícitamente lo que hacen. Resaltar lo que los hace únicos antes de describir el producto o servicio.
  • Evitar preguntas abiertas al público al inicio para prevenir respuestas múltiples y dispersas.
  • No mostrar fórmulas complejas en las diapositivas; mejor explicar los factores clave de manera clara y sencilla.
  • Mejorar la aparición del producto en el storyboard para que sea más natural, evitando la sensación de que aparece "mágicamente".
  • Hacer los elementos visuales de la aplicación más atractivos y legibles, evitando fondos oscuros en las gráficas que dificulten la lectura.
  • Resumir y simplificar la planificación de usuarios piloto, evitando sobrecargar de información las diapositivas.

Feedback relacionado con el desarrollo del proyecto​

  • Asegurarse de que los compromisos y objetivos cumplidos sean coherentes con los problemas identificados (por ejemplo, cumplimiento vs. comunicación).
  • Evaluar si las soluciones implementadas realmente funcionan y tienen el impacto esperado.
  • Entrar en detalle al explicar problemas específicos, como errores en la revisión de código, para entender mejor sus causas y posibles soluciones.
  • Las gráficas de rendimiento individual son útiles, pero se debe asegurar que sean claras y bien presentadas.
  • Cuidar la coherencia al comunicar los resultados: no decir que algo ha ido bien si hay un aspecto relacionado que ha fallado.
  • Si se muestra código fuente, evitar hacerlo público y restringir el acceso solo a personas autorizadas, como profesores.

Semana 7​

Feedback sobre la Presentación​

  • Ritmo y contenido: Buen ritmo y gran cantidad de contenido sin apresurarse.
  • Contacto visual: El presentador debe intentar mirar a todo el público.
  • Lenguaje: Está bien hablar de forma coloquial, pero hay que evitar el lenguaje soez (quizás usarlo solo una vez).
  • Estructura narrativa: El orden es mejorable, pero se cuenta bien una historia. Se recomienda unir la demo al storyboard y al inicio para que la presentación tenga un solo hilo narrativo.
  • Uso de preguntas retóricas: Se depende demasiado de ellas.
  • Uso de la mascota: Es un buen recurso.
  • Imagen de marca: Se recomienda buscar un eslogan o una imagen de marca.
  • Forma de presentar las finanzas: No hablar tanto de "gastos", sino de "inversiones".
  • Claridad en soluciones: Reducir la cantidad de veces que se mencionan las mismas soluciones para optimizar el tiempo disponible.

Feedback sobre el Desarrollo del Proyecto​

  • Diferenciación entre ideas y MVP: Separar claramente lo que pertenece a la idea de negocio y lo que se implementa en el MVP, ya que no hay tiempo para todo.
  • Evolución y métricas: Incluir una gráfica de rendimiento que muestre los movimientos entre semanas del personal y otros indicadores clave.
  • Contexto en el rendimiento del equipo: Presentar datos históricos para mostrar evolución y tendencias (ej. gráficos con flechas de tendencia o indicadores como "aura verde/roja").
  • SLA: Falta incluir acuerdos de nivel de servicio (SLA).

Semana 8​

Feedback relacionado con la presentación​

  • Se valora que haya demo, pero se sugiere mejorar su integración.
  • El anuncio es algo largo y el formato (por ejemplo, mostrarlo en un móvil grande) puede dificultar su comprensión.
  • Se recomienda simplificar el anuncio, ya que actualmente mezcla la demo y puede resultar confuso.
  • El tema de la “contraseña olvidada” no es relevante en el contexto actual.
  • La IA no se percibe claramente en la presentación; se debe hacer más visible o explicarla mejor.

Feedback relacionado con el desarrollo del proyecto​

  • Incluir número estimado de usuarios en lugar de variables genéricas para concretar mejor el planteamiento técnico.
  • Hacer más clara la trazabilidad entre los problemas que se abordan y las soluciones propuestas.
  • Las gráficas de horas/rendimiento deben mostrar segmentos de rendimiento claros, como la media y la semana actual, y utilizar una representación más técnica (por ejemplo, un vector entre dos puntos).
  • Planificar una actividad de team building, preferiblemente después de clases, para mejorar la dinámica del equipo sin interferir con el horario académico.

Semana 9​

Feedback relacionado con la presentación​

  • El killer opener pierde el factor sorpresa; se sugiere innovar más en la introducción.
  • El primer pitch está demasiado animado, lo que puede restar seriedad o claridad.
  • El análisis de competidores no convence lo suficiente; falta énfasis claro en qué los diferencia y las diapositivas no ayudan a reforzarlo.
  • El anuncio del cliente es algo largo; se recomienda acortarlo para mantener la atención.
  • El anuncio del cliente tipo bar no queda claro por qué funciona → se sugiere clarificarlo con la idea de “go 4 surprise”.
  • El equipo debería mostrarse más condensado en una sola diapositiva.
  • La demo necesita más enfoque visual (zoom en momentos clave) y más interactividad (ej., vestir a alguien como "Sorpresín" para mayor impacto visual).
  • Faltó la board del inversor, ya que el anuncio mostrado era del otro tipo de cliente.
  • La raíz del problema principal no se explica con claridad; hay que ser más específicos y concretos al definirlo.

Feedback relacionado con el desarrollo del proyecto​

  • Se deben realizar pruebas de carga (test de estrés o performance) del sistema.
  • El inicio del mercado objetivo necesita estar más racionalizado y enfocado.

Semana 10​

Feedback relacionado con la presentación​

  • Mejorar el timing de hablar con sorpresin
  • No hablar sobre el desarrollo actual del equipo.
  • No mostrar la comparación entre costes esperados y costes reales.
  • Simplificar la diapositiva del mercado objetivo.
  • Mejorar la gráfica de estimación de ingresos: mostrar solo la estimación esperada.
  • Antes del video para inversores, explicar claramente cómo gana dinero el proyecto.
  • Añadir paquetes de inversión y porcentaje de participación de la app.
  • Especificar el público objetivo de la campaña de marketing.

Feedback relacionado con el desarrollo del proyecto​

  • Definir en qué momento se tomará acción si las métricas no van bien y revisar el plan.

Semana 11​

Feedback relacionado con la presentación​

  • Inicio de la presentación ("killer opener"): Se debe innovar más para captar mejor la atención desde el inicio.
  • Estructura y orden de los elementos: No poner dos anuncios al principio, mover uno más adelante.
  • No leer las transparencias de derecha a izquierda (mejorar el orden lógico o visual de los slides).
  • Claridad en los KPIs: Si se usa un KPI como el "descarte de categoría", se debe justificar claramente su relevancia.
  • Discurso del CEO: Las palabras del CEO fueron demasiado genéricas; se sugiere un tono más auténtico o emocional (“estoy aburrido” como ejemplo provocador para hacerlo más interesante o realista).

Feedback relacionado con el desarrollo del proyecto​

  • Modelo de inversión: No referirse a "paquete de inversión", sino a "coste en función del porcentaje de inversión".
  • Costes de beneficios en la app: Tener en cuenta que los beneficios por hacer reservas en la app también representan un coste y deben reflejarse como tal.
  • Funcionalidad futura - interacción social: Considerar incluir en el futuro una funcionalidad que permita conocer gente a través de un formulario o similar

Grupo 11 - Pawtel​

Semana 1​

Feedback relacionado con la presentación​

  • Utilizar diseño homogéneo y claro.
  • Reducir textos largos y mejorar el diseño visual.

Feedback relacionado con el desarrollo del proyecto​

  • Identificar correctamente usuarios y clientes.
  • Asegurar que el MVP es viable y bien definido.

Semana 2​

Feedback relacionado con la presentación​

  • Invertir más tiempo en definir claramente qué es el proyecto en lugar de lo que no es.
  • Justificar visualmente los costes del posicionamiento sin mencionarlo demasiado pronto.
  • Explicar bien qué son los "strikes" y cómo funciona el sistema de recompensas y castigos.
  • Mostrar los mockups de manera más detallada y evitar que parezcan copias de Booking.

Feedback relacionado con el desarrollo del proyecto​

  • Hacer un mejor filtrado de competidores y definir mejor su impacto real en el proyecto.
  • Identificar con claridad el modelo de negocio y eliminar información irrelevante.
  • Justificar con datos todas las decisiones estratégicas, incluyendo los cálculos realizados.
  • Considerar diferentes modelos de monetización, no solo por transacción sino también por tráfico.
  • Identificar riesgos de manera más fundamentada y no solo basándose en preocupaciones personales.

Semana 3​

Feedback relacionado con la presentación​

  • Ajustar el equilibrio de contenido entre diapositivas con mucho y poco texto.
  • Revisar si las dobles flechas aportan valor; eliminarlas si no son necesarias.
  • Sustituir el imagotipo por un logotipo.
  • Usar fotos más homogéneas del equipo.

Feedback relacionado con el desarrollo del proyecto​

  • Analizar mejor los ingresos con un caso realista.
  • Revisar la presentación de los salarios de la Junta de Andalucía, ya que puede generar una mala impresión.
  • El plan de despliegue está bien trabajado.
  • La falta de planificación no debe considerarse un riesgo.

Semana 4​

Feedback relacionado con la presentación​

  • El número de página no se ve bien (blanco sobre rosa).
  • "Servicios extra" no se entiende bien, cambiar el nombre para mayor claridad.
  • Reducir la carga cognitiva de las diapositivas.
  • No usar anglicismos si existe una palabra equivalente en español.
  • La tarjeta de perfil de usuario parece un mock-up.
  • La presentación debería contar una historia en lugar de ser una secuencia estática de pantallas.
  • Buena transparencia en el BMC (Business Model Canvas), transmite mucha información de forma simple.
  • El inicio de la presentación es efectivo: presenta cifras y el problema de manera clara.
  • Se agradece una diapositiva que condense información clave y permita digerirla mejor.

Feedback relacionado con el desarrollo del proyecto​

  • Explicar mejor cómo se compagina el equipo full-stack con el resto.
  • La retrospectiva debe enfocarse en los problemas enfrentados y cómo se han superado, más que en una lista de tareas realizadas.
  • Incluir un reloj o indicador del progreso del proyecto.
  • Presentar el punto de equilibrio en una gráfica.
  • Refinar las métricas para que sean justas para todos los roles.
  • Las métricas deben inducir el comportamiento adecuado y no generar efectos negativos.
  • Considerar métricas negativas y normalizar el número de tareas.
  • Definir límites razonables en las métricas y evaluar desviaciones.
  • Presentar gráficos de métricas de forma individual para identificar mejor el desempeño de cada miembro del equipo.
  • Incluir métricas individuales para facilitar la evaluación final y asegurar correlación con el desempeño.
  • Agregar fechas de los usuarios piloto para dar contexto.

Semana 5​

Feedback relacionado con la presentación​

  • La presentación debe centrarse en el negocio futuro y no solo en el producto actual.
  • Opener poco atractivo, debe ser más llamativo, contar una historia que enganche y se refiera al final de la presentación. Evitar enfocarlo en inversores si el público objetivo son clientes.
  • Evitar el año 2025 en gráficas si los datos no están completos. No mezclar dimensiones en el análisis de ingresos. Representar el punto de balance con una gráfica de barras negativas y positivas junto con la línea del total.
  • Asegurar que la demo sea clara, con un video de respaldo. Tener cuidado con el zoom en presentaciones en vivo.
  • Considerar a las personas daltónicas en el diseño.

Feedback relacionado con el desarrollo del proyecto​

  • Cuidado con el modelo basado en anuncios. Los costes no serán constantes a lo largo de los 24 meses; inicialmente serán altos, luego bajarán y después disminuirán progresivamente.
  • Separar correctamente las dimensiones, ya que el número de usuarios no está directamente relacionado con la comisión mensual generada.
  • Implementar un sistema de CI/CD en lugar de hacer despliegues a última hora. Elegir bien la instancia de despliegue para evitar agotar créditos.
  • Problemas entre backend y frontend no se resuelven con UML, sino con una definición clara del contrato de la API.
  • Definir cómo se medirá si una solución está funcionando correctamente.

Semana 6​

Feedback relacionado con la presentación​

  • Terminar el "killer opener" dejando claro qué hace la aplicación para cerrar con impacto.
  • Evitar pasos innecesarios en la explicación, como registrarse, si se sobreentienden.
  • El presentador habla rápido; usar la rapidez como una habilidad efectiva y no como un defecto.
  • Usar una palabra clave o el nombre de la mascota como un recordatorio claro y repetible de la aplicación.
  • No usar frases como "como hemos dicho otras veces"; la presentación debe ser autocontenida.
  • Simplificar el análisis de rendimiento y evitar desglose excesivo por equipos para una visión más general.
  • Mostrar la landing page y el email de contacto al final para cerrar con un llamado a la acción claro.

Feedback relacionado con el desarrollo del proyecto​

  • Revisar el manejo de datos personales y el cumplimiento del RGPD, considerando si realmente son necesarios.
  • Identificar si los costes son CAPEX (gastos de capital) u OPEX (gastos operativos) correctamente.
  • Evitar soluciones "mágicas" en los storyboards; especificar claramente los procesos y los beneficios, como el buscador gratuito y las comisiones.
  • Alinear el estilo de código entre todo el equipo para evitar "malos olores" y lograr consistencia visual y funcional.
  • 600+ problemas detectados es una cantidad elevada; evaluar la gravedad y priorizar la solución.
  • Asegurarse de que, si se afirma un avance del 90%, haya pruebas y tests concluyentes.
  • En la demo, destacar los casos de uso implementados y resaltar los que se van a mostrar.

Semana 7​

Feedback relacionado con la presentación​

  • Ritmo: Demasiado rápido, dificultando la comprensión. Se recomienda hablar con más calma y estructurar mejor las ideas.
  • Diapositivas: 50 diapositivas son demasiadas para 15 minutos, especialmente considerando la demo. Reducir cantidad y optimizar contenido.
  • Estructura: La presentación tiende a enlazar ideas sin cerrar, dificultando la comprensión. Se recomienda cerrar bien cada punto antes de pasar al siguiente.
  • Storyboard: Debe introducirse de manera más natural, evitando que parezca una ocurrencia de último momento.
  • Comparativa con la competencia: Necesita más matices y claridad en el mensaje.
  • Claridad en la reserva y pago: Mostrar claramente los precios y aclarar el proceso de pago.

Feedback relacionado con el desarrollo del proyecto​

  • Enfoque del análisis de costes: Está mal planteado, especialmente en relación con el TCO (Total Cost of Ownership).
  • Rendimiento: Explicar por qué se ha enfocado de cierta manera y aclarar que todos cumplen los mínimos. La evolución del rendimiento está bien presentada, pero el estado general del proyecto no queda claro.
  • Análisis de código: Lo más relevante es la evolución del código, pero también se recomienda definir y aplicar un estilo de codificación, mejorando la configuración en herramientas como Codacy.
  • Aplicación del patrón Mediador: Explicar cómo se ha implementado en lugar de solo listar problemas y soluciones.
  • Evolución del rendimiento del equipo: No queda claro en la presentación, requiere mejor comunicación y visualización.

Semana 8​

Feedback relacionado con la presentación​

  • Usar vocabulario menos específico en el "killer opener" para no alejar a la audiencia.
  • No decir "esto es muy fácil", puede parecer condescendiente.
  • Evitar mezclar idiomas en la presentación.
  • Repetir la palabra clave que resume la idea principal para reforzar el mensaje.
  • En las tablas y gráficos, cuidar el tamaño de letra en los ejes.
  • Cambiar números grandes por abreviaciones como “K” en lugar de muchos ceros.
  • Mejorar la leyenda y numeración de ejes para mayor legibilidad.
  • Evitar poner enlaces “feos” o poco legibles.
  • Justificar mejor el impacto legal para que se vea integrado en el proyecto, no un añadido forzado.
  • No cerrar con un mensaje legal anticlimático; cuidar el ritmo narrativo.
  • El hilo documental de la presentación debe estar más claro y estructurado.
  • Retener visualmente el logotipo durante la presentación (branding constante).

Feedback relacionado con el desarrollo del proyecto​

  • Si todos los usuarios obtienen un 10, la métrica puede no ser útil; revisar el sistema de evaluación.
  • Si todo el mundo está "capado" al 10, puede que haya un problema con el diseño de la escala.
  • Priorizar el feedback de usuarios piloto en el proceso iterativo.
  • Los usuarios piloto no deben actuar como beta testers: los fallos técnicos deberían detectarse antes.

Semana 9​

Feedback relacionado con la presentación​

  • Apertura poco clara: El inicio ("killer opener") no deja claro lo que ha ocurrido; se recomienda revisar el guion para mayor claridad.
  • Audio y acento: Mejorar la calidad del audio de la demo y asegurar que el acento sea constante.
  • Estructura del contenido: Hay varios saltos de tema (por ejemplo, pasar a la demo justo después del rendimiento del equipo), se sugiere encontrar una narrativa más cohesionada.
  • Visualización de datos: El eje de beneficios en la gráfica debería permitir mostrar números negativos para una mejor interpretación.
  • Gestión del tiempo: Ha sobrado demasiado tiempo; se podría aprovechar mejor o recortar la duración.

Feedback relacionado con el desarrollo del proyecto​

  • Bug en imágenes: Existe un error relacionado con las imágenes de los hoteles que debe corregirse.

Semana 10​

Feedback relacionado con la presentación​

  • La parte técnica de la presentación debe estar resuelta antes de empezar.
  • Ha tardado mucho en comenzar ("ha tardado en salir el perro, ha tardado en arrancar").
  • Hay disonancia entre audio y video en la demo.
  • El audio de la demo no está bien afinado.

Feedback relacionado con el desarrollo del proyecto​

  • Incorporar técnicas de gamificación para enganchar a los usuarios y evitar que se salten la comisión.
  • El proto persona debe ser más general y no tan específico.
  • En el posicionamiento digital, considerar que la estacionalidad es probablemente el factor más importante para el negocio.
  • Al mencionar el uso de inteligencia artificial, evitar decir "y otras IAs"; en su lugar, especificar claramente cuáles se están utilizando.

Semana 11​

Feedback relacionado con la presentación​

  • Para el anuncio si usais transparencias quitarle el numero
  • Dejar claro la diferencia entre datos potenciales y reales
  • En la transparencia 4 de la presentacion de marketing ser mas directo

Feedback relacionado con el desarrollo del proyecto​

  • Los pawpoints afectan a los costes